DevIOの組織が抱える問題と解について #devio2020
2020/6/17〜2020/7/7の期間でDevelopers.IO 2020 CONNECT が開催しています.
7/7のDay6「クラスメソッド創立記念日」カテゴリのビデオセッションがYouTubeで公開されました.
「Managing DevIO has problems. We have solutions」というタイトルで公開しています.
本ブログでは動画でお伝えしている内容を文字でお伝えします.
お伝えるする概要は, エンジニアが組織を管理する立場に回った時に組織が抱える課題をどのように捉えて対処していくかについてお伝えします.
エンジニア目線であれば技術を用いて課題を解決していくのが多いかと思いますが, 今回は組織のあり方やどのように円滑にすべきか, 責務の明確化などといった管理的な意味合いでの解決方法を示していきます.
What is DevelopersIO
みなさんDevelopers.IOは知っていますか? Developers.IOとは言っても様々な側面を持ち合わせています. ブログは一番際立っているのではないでしょうか.
私たちが管理しているブログのタイトルがそもそもDevelopers.IOであり, 当初は弊社エンジニアの開発ブログとしてスタートしています.
次の側面としては, 動画が挙げられます. 昨年のRe:Inventの会場から投稿された動画や, 今年に入ってから増えたコンテンツまた, 今回のようなDevIO Connect 2020で投稿された動画が挙げられます.
3つ目の側面としては, イベントが挙げられます. 昨年行われた, DevelopersIO 2019 や DevelopersIO Security 2019など対面でのイベント, つまりエンジニアが登壇して情報発信をおこなう機会です.
つまりDevelopers.IOは何と言われた時の個人的な答えとしては, エンジニアとして情報発信ができる媒体であったり, 文化であったりします.
その中で開発や運用が継続的に必要なものはブログが主になります.
実際に私はそこの管理を進めています.
We have got in trouble
管理を始めたタイミング, つまり前の担当者から引き継いだ時は技術的な課題と何をするかが短期的に見えている状態でした.
なのですでに入っているタスク, 新たに追加されるタスク, 例えばバグの発見やUI改善などが入ってきても問題なく対応できます.
そしてタスクをアドホックに対応しても影響はありません.
ですが時がたつと, 今まで見えなかっただけで実は積まれてたタスクや追加されているタスク, そして外的要因でブログの運営とは直接関係ないが運用で必要なタスクが積まれていきます.
その結果, 簡単にタスクはいっぱいになります.
いっぱいになっても積まれていくタスクを処理しても先が見えません.
タスクの処理順序も考慮できないのでタスクを積んだ人からすると, いつ終わるのかが気になります.
さらに悪いことに, 結果として積まれるだけ積まれてブラックボックス化していきます.
どうするべきだったのでしょうか. 1つづつ要因を紐解いて解決に向かっていきましょう.
Principle of solutions
まずは問題解決をするための行動指針を考えます.
抱えている問題は, 普段携わっているような内容ではなく得意領域でもありません.
そして問題を抱えていることは分かりますが, 問題の不透明性も高いです.
そこで3つの原則を基に問題解決の方法と実施を行うことにしました.
fail fast, keep practice
失敗は目に見えています. 私がした選択が1つも誤りを生まずに進む可能性はあるでしょうか.
なのでとにかく小さいイテレーションで思考と実践を積み上げていきます.
そして失敗から多くのことを学び, 常にアップデートするようにしていきます.
done is better than perfect
先ほどの話とも大きく関連しますが, はじめから完璧を目指しません. 目指せないので目指しません.
なのでイテレーションごとに達成することを明確にしてすすめていきます.
do not be a dictator
私たちは管理者という立場にあたります. 管理者と開発者と違うのはただの役割です.
どちらが偉いという話ではありません.
しかし最終的に判断を下すのは私たちになります.
だからこそ権力を行使するということがどういうことか慎重に捉え, 横暴な振る舞いをしないことを常に心がけます.
Build a organization
次は組織をどのように立ち上げていくかを考えます.
design a framework
組織にとって最も重要なことは何でしょうか. 全員の方向を揃えて行動方針を明白にすることでしょう.
なのでまずは, 私たちが進んでいく方向を旗印として策定し, それをデザインしていきます.
つまり, ビジョンや文化, 目標といったものを策定していきます.
ビジョンや文化については非常に抽象的な概念になります. なぜ考える必要があるのでしょうか.
それは組織の存在意義, どんな価値を提供したいかを明確にするためです.
明確とは言いつつもかなり抽象的な事象なので矛盾を感じますね...
話を戻すと, 組織がどこに向かっているのか, 遠くにあるゴールを共有するためにビジョン, 文化, 目標を定めます.
Code of Conduct
次に考えるべきことは行動指針です.
つまり組織の中で個人がどのような行動を起こすべきかを考えて共有します.
ビジョンや文化が組織単位でどのような方向に向かっていくかであるのに対して行動指針は個人単位でその方向に進むための一つの判断基準になります.
なのでDevelopersIOに携わる人がどのような考えで行動すべきかビジョンよりは明白でありつつも, 一言で言えるような内容として示していきます.
make it clear
ビジョンや目標, 行動指針を明白にしたら次はそれを伝えましょう.
携わる人に伝わるようにドキュメントに落とし込んだり, ドキュメントを伝えると言ったことを行います.
What is most important
今まで組織のコアをどのように作成していくかを考えてきました.
ここからは実際に私たちが抱えた課題と対処についてお伝えしていきます.
私たちはタスクをたくさん抱え, 大変見通しが悪い状態になりました.
どのタスクから対応すべきでしょうか. タスクの山に手を入れてランダムに対応していくべきでしょうか.
まるで宝探しです. 実際は泥の山に手を突っ込んでいる気分ですが.
またブログに携わる立場は複数あります.
執筆者は普段と変わらない状況, 執筆のし易さを求めます.
管理者は管理に関する問題と, サイトの閲覧数などといったメトリクスを気にかけます.
開発者はより新しい機能の追加を求めます.
ひとえに1つのサービスでも受け取り手で何から対応すべきかの考えが違います. どれが正しくてどれが誤っているということではありません.
なので管理する側は常に視座を高くし優先度をつけることが重要になります.
先ほどビジョンを考えました.
私たちのビジョンでは, 読者により良い体験を届けることと, 企業活動のシナジーに重きを置いています.
なのでユーザ体験が最も優先度が高く, 次に管理の不透明さをなくすこと, 企業活動のシナジー...といった形で優先度をつけ, それぞれのタスクがどれに当てはまるかを考えて対応していきます.
優先度を決める必要があるのと同時に対応しないタスクは明確に破棄するべきでしょう.
タスクは量が増えるほどに見通しが悪くなります.
後でやるならいつ頃までに対応するか優先順位を付け対応しないものは捨てましょう.
最後に私たちは独裁者のように振る舞ってはいけません. 確かに最終的な決定権は私たちが持っています.
ですが意思表明は自由であり, 意思決定は平等であるべきです. 権限は職責群に付与されるものであって地位を表すものではありません. 決定をするまでの議論は行うべきでしょう.
Why I cannot finish tasks ?
私たちはタスクの優先度付けに成功しました.
しかしタスクがなぜ片付かなかったかをもう少し考える必要があります.
タスクが片付かないのはつまりタスクが終わらないということで, タスクの粒度にばらつきがあったことが原因です.
つまりタスクを書いた人はわかるが他の人には伝わらない内容であるとか, 壮大すぎて終わる気配がないなどの状態でした.
それではどのように粒度を揃えるべきでしょうか.
一番重要なのは自分自身が模範となるように, つまり自分自身がタスクを作成する場合にはタスクの背景や終了条件, そしてタスクの大きさに対して十分な注意を払います.
次に考えるべきことはテンプレートを利用した一種の矯正に近い形で粒度を揃えます.
管理する側の人数は少数であっても執筆者や開発者は非常に多く, 毎月のように増えていきます.
この状態で口頭で伝えてもタスクの粒度は揃わないでしょう.
なのでタスクに対してテンプレートを設けることで矯正を行います.
今回は開発者が作成するIssueやPull Requestを作成する際の粒度を揃えることを対象とします.
なのでGitHubのIssue TemplateとPull Request Templateを活用することで誰にとってもわかりやすいタスクを開発者が書きやすい状態を作りました.
このことで手間をかけずにある程度タスクの粒度を小さくシンプルに, そして均質に保つことができます.
Who do the tasks ?
タスクを十分に対応できるレベルまで落とし込むことができました.
組織が十分に小さくて, 開発者が貴方と私だけであればタスクの分配はできるでしょう.
しかし開発者が複数人いた場合はどうでしょうか.
どのタスクを自分自身で対応すべきか, どのタスクは開発者にまかせたいか私は理解しています.
また全てのタスクを一人で行うより, 開発者に任せる方が効率的です.
私たちは恵まれたことに社内有志の開発者がコントリビュートを申し出てくれました.
開発者が見つけたバグや小さな機能修正は取り込めます.
ですが機能追加などのタスクをふることができていません.
理由はシンプルです. 私が「助けてください」しか言っていないからです.
伝えなければいけないのは何をどのようにして欲しいかです.
どのタスクを開発者たちに任せるべきか伝えましょう.
タスクの属性として明示できるなら活用しましょう.
GitHubであればIssueに対して「help wanted」のタグを付与すればどのタスクに対応が必要であるかを明示できます.
開発者側が起票したが管理者が整理する前のタスクは「waiting triage」といったタグを付与して状態を明示的に示すべきでしょう.
言葉でのコミュニケーションももちろん重要で, 開発者と話す機会を設けるべきではありますが, タスクを可視化することで何をすべきかわかりやすい状態を保ちます.
そしてどのように対応を進めるかも伝えます.
つまり開発でいけば, Pull Requestのレビュアーに誰を指名するかや, 命名の規則などにあたります.
Gitで管理している場合はContributingガイドを作成してリポジトリに含めることで簡単に開発者に提示することができます.
Where are documents ?
ほとんどの問題は快方に向かっています. 短期的にみれば十分な改善が見込まれるでしょう.
次は中期や長期にソフトウェアのブラックボックス化を防ぐことを考えていきましょう.
GitHub Organizationに参加して開発を始める方法はどこで参照できるのでしょうか.
ブログ執筆の方法はどこにあるのでしょうか.
人が少ない場合ははSlackなどのチャットツールでの伝達で間に合います.
ですが時が立って情報を人づてに聞いて, またその情報を誰かに伝えて...
私たちがしたいのは伝言ゲームではありません. 情報の伝達です.
情報伝達を1つの信頼できる情報源から発信できるようにドキュメントを作成しましょう.
もちろん誰もが見れる場所に書く必要があります.
ドキュメントを書くと言うことはそれをメンテナンスする必要も発生することを意味します.
信頼できる情報源として保持し続けるのは本当に大変です. ですがドキュメントを書かないと後から情報伝達の手法で苦しむことになります.
How to achieve our goal ?
多くの問題は片付きました. ビジョンに向かって一歩ずつタスクをこなして進んでいます.
ビジョンはとても遠い抽象的な目標です. 私たちが今どのくらいビジョンを達成しているかを図ることは難しいです.
先行きが見えないことは徐々に不安をうんでいきます. 不安の結果として疲弊感も出てきます.
この疲弊感を避けるためにも毎月などの単位でマイルストーンをしいていきます.
マイルストーンでは具体的に, 例えば管理画面のUIを変更するや, 訪問者数を1,000人増やすなどできるだけ定量的なものにします.
ビジョンが抽象的な分, マイルストーンは具体的にして短期的にやるべきことを明確にします.
そして目標がどれだけ達成できたかやどのくらいの改善が見込まれたか, 逆になぜ達成できなかったかの振り返り材料として活用でき今後の役にも立ちます.
Take Aways
いろいろお伝えしてきましたが, とても当たり前のことを並べていると感じているかと思います.
課題は抱えている気がするけど正体がわからない人や, 今まで組織での動き方を考えたことがない私のようなエンジニアが考えるきっかけになれが幸いです.
セッションの振り返りをしていきましょう.
- 組織, ビジョンをデザインして旗揚げをしましょう
- 伝えるべきことは明白にしましょう. そしてコミュニケーションを取りましょう
- 多少のつまづきや面倒に感じる場面はたくさんあります. ですが諦めずに続けるしかありません.
最後になりますがプロセスに異常こだわるプロセスツァーにはならないでください.
手法は一般論であり個々の組織に最適化されたものではありません. 常にコミュニケーションをとって柔軟に対応しましょう.
